Network accounting involves the collection of various types of records while sending and receiving information over a network. Examples of such records may include, but are not limited to a session's source, destination, user name, duration, time, date, type of server, volume of data transferred, etc. Armed with such accounting records, various services may be provided that require network usage metering of some sort.
Prior art FIG. 1 illustrates an exemplary system 100 for performing network accounting in accordance with the prior art. As shown, a plurality of information sources 102 is provided for collecting information. It should be noted that the information sources 102 may include a firewall, router, workstation, or any other network device that is subjected to a flow of information.
Coupled to the information sources 102 is an aggregator 104. In use, the aggregator 104 receives records from the information sources 102 for the purpose of aggregating the same. In the present description, aggregation refers to consolidation, analysis, or any other type of handling of the data. Once aggregated, the records may be used to afford any desired type of service, OSS (Operational Support System), and/or BSS (Business Support System), i.e. billing, fraud detection, network monitoring, traffic engineering, etc.
Prior art FIG. 2 illustrates a sample method 200 carried out by the aggregator 104 of the system 100 shown in FIG. 1. It should be noted that the present method 200 is illustrative in nature, and should not be construed as limiting on the term “aggregation.” Of course, aggregation may be carried out in a variety of different ways using varying practices.
As shown, records are received from the information sources 102 in operation 202. It is then determined in decision 204 as to whether the record is the start of a new aggregation. This may be accomplished by identifying a particular aggregation field, regular attribute, and/or “key” in the received records. Such keys often determine an aggregation bin, and may be any type of policy of indication which signifies that a new aggregation has been started, or an update and/or termination operation is necessary. Thereafter, a new aggregation is started if it is determined in decision 204 that such is necessary. Note operation 206. If not, aggregation is continued on a normal basis, as indicated in operation 208.
One problem with such a method is that latency is incurred because data is held back before being exposed in real-time. In the context of the present description, a “real-time” environment is that which ensures no more than a fixed latency. Unfortunately, the service, OSS, and/or BSS can not be initiated until after the data is exposed.
Prior art FIG. 3 is a flowchart illustrating an evaluation procedure 300 that is executed in parallel periodically with the method of FIG. 2. Similar to before, the present method 300 is illustrative in nature, and should not be construed as limiting on the term “aggregation.” Of course, aggregation may be carried out in a variety of different ways using varying practices.
Initially, an evaluation is carried out to determine whether an update or stop threshold is met. Note decision 302. It should be noted that an update or stop threshold may be any policy that triggers the aggregation to be updated or terminated, respectively. Again, a particular aggregation field, regular attribute, and/or “key” may be used to determine whether an update or stop threshold is met. If it is decided in decision 302 that an update or stop threshold is met, the aggregation may be updated or terminated appropriately in operation 304. Finally, a certain periodic time is allowed to elapse before re-initiating the evaluation procedure 300. Note decision 306.
Yet another problem arises as a result of the above evaluation procedure 300. Specifically, after an event occurs that renders the aggregation ready to be updated or stopped, latency is incurred while waiting for the periodic evaluation procedure 300 to initiate so that the appropriate action takes place. Again, this latency may be unacceptable in a real-time environment.
There is therefore a need for a technique of reducing latency in the aggregation process.